<?xml version="1.0" encoding="utf-8"?>
<!--
                                                                                     
 h       t     t                ::       /     /                     t             / 
 h       t     t                ::      //    //                     t            // 
 h     ttttt ttttt ppppp sssss         //    //  y   y       sssss ttttt         //  
 hhhh    t     t   p   p s            //    //   y   y       s       t          //   
 h  hh   t     t   ppppp sssss       //    //    yyyyy       sssss   t         //    
 h   h   t     t   p         s  ::   /     /         y  ..       s   t    ..   /     
 h   h   t     t   p     sssss  ::   /     /     yyyyy  ..   sssss   t    ..   /     
                                                                                     
	<https://y.st./>
	Copyright © 2016 Alex Yst <mailto:copyright@y.st>

	This program is free software: you can redistribute it and/or modify
	it under the terms of the GNU General Public License as published by
	the Free Software Foundation, either version 3 of the License, or
	(at your option) any later version.

	This program is distributed in the hope that it will be useful,
	but WITHOUT ANY WARRANTY; without even the implied warranty of
	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
	GNU General Public License for more details.

	You should have received a copy of the GNU General Public License
	along with this program. If not, see <https://www.gnu.org./licenses/>.
-->
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<base href="https://y.st./en/weblog/2016/05-May/16.xhtml" />
		<title>I upgraded to Debian Testing without thinking about the consequences first. &lt;https://y.st./en/weblog/2016/05-May/16.xhtml&gt;</title>
		<link rel="icon" type="image/png" href="/link/CC_BY-SA_4.0/y.st./icon.png" />
		<link rel="stylesheet" type="text/css" href="/link/basic.css" />
		<link rel="stylesheet" type="text/css" href="/link/site-specific.css" />
		<script type="text/javascript" src="/script/javascript.js" />
		<meta name="viewport" content="width=device-width" />
	</head>
	<body>
		<nav>
			<p>
				<a href="/en/">Home</a> |
				<a href="/en/a/about.xhtml">About</a> |
				<a href="/en/a/contact.xhtml">Contact</a> |
				<a href="/a/canary.txt">Canary</a> |
				<a href="/en/URI_research/"><abbr title="Uniform Resource Identifier">URI</abbr> research</a> |
				<a href="/en/opinion/">Opinions</a> |
				<a href="/en/coursework/">Coursework</a> |
				<a href="/en/law/">Law</a> |
				<a href="/en/a/links.xhtml">Links</a> |
				<a href="/en/weblog/2016/05-May/16.xhtml.asc">{this page}.asc</a>
			</p>
			<hr/>
			<p>
				Weblog index:
				<a href="/en/weblog/"><abbr title="American Standard Code for Information Interchange">ASCII</abbr> calendars</a> |
				<a href="/en/weblog/index_ol_ascending.xhtml">Ascending list</a> |
				<a href="/en/weblog/index_ol_descending.xhtml">Descending list</a>
			</p>
			<hr/>
			<p>
				Jump to entry:
				<a href="/en/weblog/2015/03-March/07.xhtml">&lt;&lt;First</a>
				<a rel="prev" href="/en/weblog/2016/05-May/15.xhtml">&lt;Previous</a>
				<a rel="next" href="/en/weblog/2016/05-May/17.xhtml">Next&gt;</a>
				<a href="/en/weblog/latest.xhtml">Latest&gt;&gt;</a>
			</p>
			<hr/>
		</nav>
		<header>
			<h1>I upgraded to Debian Testing without thinking about the consequences first.</h1>
			<p>Day 00436: Monday, 2016 May 16</p>
		</header>
<p>
	I decided to upgrade my <a href="https://www.debian.org./">Debian</a> system to the &quot;Testing&quot; branch today.
	The idea was that if I was on the Testing branch, I&apos;d have newer versions of Web browsers, so I would know if the <a href="https://y.st./en/URI_research/SNI_bug.xhtml"><abbr title="Server Name Indication">SNI</abbr> bug</a> fix had actually made it into any of the Web browsers in Debian.
	In the process of upgrading, I managed to bork <a href="apt:aptitude">Aptitude</a>.
	With Aptitude out of commission, I was pretty worried.
	I still had a working copy of <a href="apt:apt"><abbr title="Advanced Package Tool">APT</abbr></a>, but Aptitude is said to have better dependency handling and I don&apos;t like the idea of having it out of commission indefinitely.
	Once I finished the upgrade with <abbr title="Advanced Package Tool">APT</abbr>, Aptitude returned to working order, so I guess that everything&apos;s fine now.
	Along the way, people in <a href="ircs://irc.oftc.net.:6697/%23Debian-Next">#Debian-Next</a> recommended that I remove all software that wasn&apos;t from the Debian repository and remove those repositories from my source list, so I removed <a href="apt:qtox">qTox</a> and <a href="apt:utox">uTox</a>.
	I don&apos;t really use those applications any more anyway and have sort of lost interest in them for now.
	Once they have their own <abbr title="Uniform Resource Identifier">URI</abbr> scheme, I&apos;ll have a renewed interest, but for now, linking to my Tox &quot;account&quot; is more trouble than it&apos;s worth.
	I&apos;ve also lost interest in <a href="apt:torchat">TorChat</a> and would uninstall that as well if it weren&apos;t for the fact that TorChat is the main way that two of my siblings usually contact me.
	During the upgrade, I lost my network connection due to the fact that <a href="apt:tor"><abbr title="The Onion Router">Tor</abbr></a> got uninstalled, and I was worried that I wouldn&apos;t be able to reinstall it.
	My source list contains nothing but onion-based repositories, so without <abbr title="The Onion Router">Tor</abbr>, I would be kind of stuck.
	Several things were to be uninstalled during the upgrade and I should have paid better attention to what would be lost instead of just spot checking to be sure that certain packages weren&apos;t on the list.
	Luckily, <abbr title="The Onion Router">Tor</abbr> wasn&apos;t to be removed, only upgraded, so the replacement had already been downloaded before the old version was uninstalled.
	After the upgrade was complete, I regained my network connection.
	Testing Web browsers didn&apos;t go as I&apos;d hoped though.
	<a href="apt:arora">Arora</a> isn&apos;t in Testing (though it&apos;s in both Stable and Unstable), so I couldn&apos;t check to see if the fix from Qt had worked.
	I&apos;m guessing that <a href="apt:konqueror">Konqueror</a> might use the Qt networking library as well, but if it does, the fix either doesn&apos;t work or hasn&apos;t made it to Debian and/or that Web browser yet.
</p>
<p>
	Having finished the upgrade, I began work on <a href="https://git.vola7ileiax4ueow.onion/y.st./include.d">include.d</a> again.
	That&apos;s when I found my mistake.
	There was a reason that I hadn&apos;t upgraded my system to Testing yet.
	While having newer software on my client machine can help me test Web browser bugs, I need include.d to run on Debian Stable&apos;s version of <abbr title="PHP: Hypertext Preprocessor">PHP</abbr>, so that&apos;s the version of <abbr title="PHP: Hypertext Preprocessor">PHP</abbr> that I need to test on.
	The <code>php</code> command on the command now points to <abbr title="PHP: Hypertext Preprocessor">PHP</abbr>7, and while that has many awesome new improvements, I should wait until those features are more widespread before using them.
	I do have the <code>php5</code> command/binary at my disposal, but even that is too new to work for testing; it&apos;s at version 5.6.21.
	I backed my data up before I upgraded my system, but now I&apos;m going to need to back up my data again and downgrade.
	I need my <abbr title="PHP: Hypertext Preprocessor">PHP</abbr> 5.6.20 back.
	Then again, it&apos;s only one version behind.
	As a <a href="https://secure.php.net./ChangeLog-5.php">bug fix</a> release, it might not be too problematic to use this newer <abbr title="PHP: Hypertext Preprocessor">PHP</abbr> version.
</p>
<p>
	Needing a break from the more tiresome parts of include.d development, I switched to the <abbr title="Uniform Resource Identifier">URI</abbr> branch to begin work on the new scheme-specific classes.
	The first scheme on the alphabetically-arranged list was <a href="https://tools.ietf.org./html/rfc6733"><code>aaa:</code></a>, but I found that that scheme, along with <code>aaas:</code>, doesn&apos;t conform to <a href="https://tools.ietf.org./html/rfc3986"><abbr title="Request for Comments">RFC</abbr> 3986</a>.
	I thought that I&apos;d be able to put off the work on non-conformant schemes, but it looked like I wasn&apos;t going to be doing that after all.
	I needed an interface that the main <abbr title="Uniform Resource Identifier">URI</abbr> class implemented, but that non-conformant <abbr title="Uniform Resource Identifier">URI</abbr> classes also implemented.
	If a function or method wants a conformant <abbr title="Uniform Resource Identifier">URI</abbr>, it can request that its argument(s) be of the main <abbr title="Uniform Resource Identifier">URI</abbr> class, but if it only needs something that behaves mostly like a <abbr title="Uniform Resource Identifier">URI</abbr>, it can request that its argument(s) only implement this interface, which has the method signature of every method from the main <abbr title="Uniform Resource Identifier">URI</abbr> class.
	For implementing classes to truly behave like <abbr title="Uniform Resource Identifier">URI</abbr> objects though, they need to implement every interface that the main <abbr title="Uniform Resource Identifier">URI</abbr> class implements.
	I found that interfaces cannot implement other interfaces, but unlike non-interface classes, they can extend multiple classes.
	That feature is mentioned in the <a href="https://secure.php.net./manual/en/language.oop5.interfaces.php">manual</a>, but I didn&apos;t notice that and I had to discover it for myself.
	I find it strange that non-interface classes can only have up to one parent class while interfaces can have as many parent interface classes as necessary, but I suppose that it works.
	It would be nice to have multiple parent classes for certain non-interface classes though.
</p>
<p>
	While I was debugging, jonez mentioned <a href="http://bbsengine.org./">bbsengine</a> on <a href="ircs://irc.oftc.net.:6697/%23PHP">#PHP</a>, so I asked about that.
	I asked about what bbsengine was, and they seemed a bit hurt that I didn&apos;t already know.
	As it turns out, it&apos;s a framework that jonez started building a few years ago.
	Trying to mend hurt feelings, I mentioned that I&apos;m not the best developer; I don&apos;t know many frameworks and I either use code as-is, not knowing what frameworks it makes use of, or write the functionality that I need into my own framework.
	Jonez said that they&apos;d be honored if I reviewed bbsengine, so again, trying to avoid hurting people, I agreed to do it.
	I just bought myself some extra work.
	Perhaps I&apos;ll learn something from it though.
	At least it&apos;s written in <abbr title="PHP: Hypertext Preprocessor">PHP</abbr>, so I stand a chance of understanding it, and it&apos;s covered by the <abbr title="GNU&apos;s Not Unix">GNU</abbr> <abbr title="Lesser General Public License">LGPL</abbr>, so I don&apos;t have to waste time looking at proprietary code.
	(I did check the license before agreeing to review the code.) I&apos;m confused as to why it would be an honor for <strong>*me*</strong> to review the code, but I might look into that tomorrow after downgrading my Debian installation, assuming that I even decide to do that.
</p>
<p>
	I noticed that the Tox team is <a href="https://blog.tox.im./2016/04/01/litigation/">dealing with trademark issues</a>.
	It seems that someone claiming to be related to the Tox group by calling themselves &quot;Project Tox&quot;.
	I&apos;m not sure what&apos;s going on, but it sounds like the real Tox developers think that the impostors may be <abbr title="National Security Agency">NSA</abbr> officers that are building botnet software into their modified Tox software.
	I sincerely hope that there&apos;s actual evidence that &quot;Project Tox&quot; is doing this.
	Either missing source code or source code containing such antifeatures would be perfect evidence, for example.
</p>
<p>
	Speaking of trademarks, it seems that Debian Testing has Firefox.
	Not <a href="apt:iceweasel">Iceweasel</a>, but <a href="apt:firefox-esr">Firefox</a>.
	Mozilla has publicly acknowledged that Debian&apos;s security patches, system-related functionality patches, and packaging are not in violation of Mozilla&apos;s trademark policy.
	They have <a href="https://bugs.debian.org./cgi-bin/bugreport.cgi?bug=815006#5">requested that Debian use the Firefox branding once more</a>.
	Mozilla&apos;s also decided to offer better support for stability, providing an extended support release, which only provides security patches for a while; it doesn&apos;t include new and potentially-unstable features.
	This is more in line with what Iceweasel has/had, but these Firefox releases don&apos;t have support for as long as Iceweasel&apos;s do.
	For some reason, the Debian team is meeting them halfway though.
	The Debian team has agreed to use Firefox&apos;s new extended release version whenever the last one expires.
	This seems like a downgrade as far as Debian&apos;s stability is concerned.
	That said, I don&apos;t use Debian for the stability, I use it for the freedom.
	Debian is one of only two operating systems that I know of that are committed to using only free components.
	The <abbr title="Free Software Foundation">FSF</abbr> keeps a list of distributions that they like, but as far as I know, these distributions make no such commitment in regards to non-software components, such as graphics and manuals.
	The <abbr title="Free Software Foundation">FSF</abbr>&apos;s guidelines allow these things to be nonfree, but personally, I don&apos;t find this to be acceptable.
	Back on the topic of trademarks, it was pointed out that <a href="https://bugs.debian.org./cgi-bin/bugreport.cgi?bug=815006#10">Mozilla trademark policy prohibits sale of binaries</a>, but it seems to be believed that Debian falls into a loophole because they <a href="https://bugs.debian.org./cgi-bin/bugreport.cgi?bug=815006#15">build their own binaries</a>.
	I think that this loophole is simply a miswording on Mozilla&apos;s part, and that while this interpretation does follow the word of the policy, it doesn&apos;t follow the spirit of it.
	In any case though, it seems that it is believed that Mozilla&apos;s trademark policy is now close enough to that of other projects that it&apos;s palatable to the Debian team, so Iceweasel will soon be no more.
	Annoyingly, the switch to Firefox reset my default search engine to be Google, though the rest of my settings seem to have been preserved.
</p>
		<hr/>
		<p>
			Copyright © 2016 Alex Yst;
			You may modify and/or redistribute this document under the terms of the <a rel="license" href="/license/gpl-3.0-standalone.xhtml"><abbr title="GNU&apos;s Not Unix">GNU</abbr> <abbr title="General Public License version Three or later">GPLv3+</abbr></a>.
			If for some reason you would prefer to modify and/or distribute this document under other free copyleft terms, please ask me via email.
			My address is in the source comments near the top of this document.
			This license also applies to embedded content such as images.
			For more information on that, see <a href="/en/a/licensing.xhtml">licensing</a>.
		</p>
		<p>
			<abbr title="World Wide Web Consortium">W3C</abbr> standards are important.
			This document conforms to the <a href="https://validator.w3.org./nu/?doc=https%3A%2F%2Fy.st.%2Fen%2Fweblog%2F2016%2F05-May%2F16.xhtml"><abbr title="Extensible Hypertext Markup Language">XHTML</abbr> 5.1</a> specification and uses style sheets that conform to the <a href="http://jigsaw.w3.org./css-validator/validator?uri=https%3A%2F%2Fy.st.%2Fen%2Fweblog%2F2016%2F05-May%2F16.xhtml"><abbr title="Cascading Style Sheets">CSS</abbr>3</a> specification.
		</p>
	</body>
</html>

